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A Session Initiation Protocol (SIP) Media Feature Tag for MIME 
Application Subtypes 


Abstract 


The caller preferences specification for the Session Initiation 
Protocol (SIP) allows a caller to express preferences that the call 
be routed to a User Agent (UA) with particular capabilities. 
Similarly, a specification exists to allow a UA to indicate its 
capabilities in a registration. Amongst those capabilities are the 
type of media streams the agent supports, described as top-level MIME 
types. The ‘’application’ MIME type is used to describe a broad range 
of stream types, and it provides insufficient granularity as a 
capability. This specification allows a UA to indicate which 
application subtypes the agent supports. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5688. 
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Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
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include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 
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1. Introduction 


The caller preferences specification [RFC3841] for the Session 
Initiation Protocol (SIP) [RFC3261] allows a user to express 
preferences for the routing of SIP requests. These preferences are 
expressed as a set of desired capabilities and characteristics of a 
receiving agent. When a user agent registers to the SIP network, it 
includes, as part of its registration, its own capabilities and 
characteristics [RFC3840]. These capabilities are stored as part of 
the registration, and then made available to the proxy in the 
network. When a request arrives at the proxy with caller 
preferences, the preferences in the request are compared with the 
supported characteristics and capabilities stored in the 
registrations, and the result is used to select the target user 
agents for the request. 


RFC 3840 makes use of media feature tags [RFC2506]. Each tag has a 
name and a type. The tags defined in RFC 3840 describe some of the 
basic characteristics of user agents, including whether or not they 
are automata (the sip.automata tag), their class (the sip.class tag), 
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whether they support media in one or both directions (the 
sip.duplex), and whether they are a conference focus (sip.isfocus). 
These tags also include SIP capabilities, including the schemes 
supported by the agent (sip.schemes), the methods (sip.methods), and 
the event packages (sip.events) [RFC3265]. 


RFC 3840 also defines media feature tags for multimedia stream types. 
There is a media feature tag defined for each top-level media type -- 
sip.audio for audio streams, sip.video for video streams, and so on. 
The primary use case for this is to correctly deliver multimedia 
sessions to the user agent that supports that media type. Consider a 
caller on a videophone that wants to have a video call with another 
user. That user has two devices -- a mobile phone that only supports 
audio and a videophone. We’d like to deliver the videophone call to 
the videophone as a first priority, and only ’ring’ the mobile device 
for an audio-only call if the user is not present on the videophone. 


RFC 3840 defines media feature tags for each and every top-level 
media type, including ’application’. This media type covers an 
extremely broad range of subtypes -- multiplayer games of all sorts, 
shared whiteboards and application sharing, and so on. With audio 
and video, where there is often a common codec supported by agents 


(i.e., a common subtype). Consequently, if a caller wants an audio 
session, routing the request to any user agent that supports audio is 
likely to result in successful communications. However, with 


application streams, just routing a request to an agent that supports 
*some* application stream isn’t useful; application streams for 
different applications are wildly different. Consequently, the 
application media feature tag does not provide sufficient granularity 
for call preferences. The specific application subtype needs to be 
indicated as well. 


To remedy this, this specification defines a new media feature tag 
that indicates which application subtypes are supported by the agent 
for streaming. The name of this media feature tag is '’Sip.app- 
subtype’. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 

3. sip.app-subtype Media Feature Tag 
The ’sip.app-subtype’ media feature tag is of type token with a case- 


insensitive equality relationship. Its value can be any registered 
or private MIME application subtype compliant to the subtype-name 
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grammar defined in [RFC4288]. When included in the Contact header 
field of a REGISTER request, an agent SHOULD include all application 
subtypes that it can support as streaming formats. An application 
subtype is supported if the user agent would be capable of processing 
a Session Description Protocol (SDP) [RFC4566] offer [RFC3264] that 
contained that subtype as a format in the m-line of the SDP. 


When included in the Accept-Contact or Reject-—Contact header field, 
it indicates a desire on the part of a User Agent Client (UAC) to be 
connected to a User Agent Server (UAS) that can support or cannot 
support, respectively, streaming using that application subtype. 


It is important to note that this media feature tag is only 
indicating the streaming media types that a user agent is capable of 
supporting. It says nothing about the functionality provided by the 
user agent itself or the MIME types that the agent can send or 
receive in SIP messages or emails. For example, let us assume that a 
SIP user agent is capable of supporting a chess game. The game is 
played by each user sending chess moves as binary objects over UDP 
between a pair of user agents. Those objects have a MIME type of 
"application/example". When a UA includes the sip.app-subtype media 
feature tag in a Contact header field with a value of "example", it 
means that the UA can handle a SIP INVITE that contained an SDP with 
an application media line and format of "example". It does not mean 
that the SIP user agent is a chess application, or that the user 
agent can accept SIP requests that include bodies of type 
"application/example". To indicate that a user agent can accept SIP 
requests that include bodies of type "application/example", the agent 
would utilize the "type" media feature tag as defined in [RFC3840]. 


A consequence of this is that, as new streaming media type formats 
are defined (such as game stream formats, whiteboard session formats, 
and so on), they SHOULD be defined using the SDP application stream 
and utilize a MIME application subtype. 


4. Example 
The following is an example SIP REGISTER message fragment indicating 
usage of this media feature tag. The REGISTER indicates that the UA 


can participate in application media sessions utilizing exchange of 
objects of type "“application/example". 
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REGISTER sip:example.com SIP/2.0 

To: sip: Y@example.com 

Contact: <sip:Y1@pc.example.com> 
;methods="INVITE, ACK, OPTIONS, BYE, CANCEL" 
;uri-user="<Y1>" 
;uri-domain="example.com" 
; audio 
;schemes="sip" 
;mobility="fixed" 
;class="personal" 
;+sip.app-subtype="example" 


Such a registration indicates that an INVITE of the following form: 


INVITE sip:Y@example.com SIP/2.0 
To: sip: Y@example.com 
Content-Type: application/sdp 
Content-Length: 


v=0 

o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 
c=IN IP4 192.0.1.2 

t=0 0 

m=audio 49170 RTP/AVP 0 

m=application 8493 udp example 


would be accepted by the UA. The SDP in the INVITE indicates an 
audio session and an application session that runs over UDP and 
exchanges "application/example" object formats. 


5. Security Considerations 


When present in a REGISTER request, this media feature tag gives 
information on the set of supported application media streams. It is 
possible that this information is sensitive, providing insight into 
the capabilities of a product. These considerations are already 
discussed in RFC 3840, and those considerations apply here as well. 
Applications that utilize this media feature tag SHOULD provide a 
means for ensuring its integrity. Similarly, the media feature tag 
should only be trusted as valid when it comes from the user or user 
agent described by the feature tag. As a result, mechanisms for 
conveying the feature tag SHOULD provide a mechanism for guaranteeing 
authenticity. 


6. IANA Considerations 


This specification adds a new media feature tag to the SIP Media 
Feature Tag Registration Tree defined in RFC 3840 [RFC3840]. 
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Media feature tag name: sip.app-subtype 
ASN.1 Identifier: 1.3.6.1.8.4.24 


Summary of the media feature indicated by this tag: This feature tag 
indicates the MIME application subtypes supported by the agent for 
purposes of streaming media. 


Values appropriate for use with this feature tag: Token (equality 
relationship). 


The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 
This feature tag is most useful in a communications application, 
for describing the capabilities of a device, such as a phone or 
PDA. 


Examples of typical use: Routing a call to a phone that can support 
a multiplayer game. 


Related standards or documents: RFC 5688 


Security Considerations: Security considerations for this media 
feature tag are discussed in Section 5 of RFC 5688. 
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